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Abstract 


This document provides common terminology and metrics for 
benchmarking the performance of sub-IP layer protection mechanisms. 


The performance benchmarks are measured at the IP layer; 


may be provided at the sub-IP layer. 


protection 
The benchmarks and terminology 


can be applied in methodology documents for different sub-IP layer 


protection mechanisms such as Automatic Protection Switching 
(VRRP), 
and Multiprotocol Label Switching Fast Reroute 


Virtual Router Redundancy Protocol 
(HA), 
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(APS), 
Stateful High Availability 
(MPLS-FRR) . 
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Internet Engineering Steering Group 
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any errata, 
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1 


Introduction 


The IP network layer provides route convergence to protect data 
traffic against planned and unplanned failures in the Internet. Fast 
convergence times are critical to maintain reliable network 
connectivity and performance. Convergence Events [6] are recognized 
at the IP Layer so that Route Convergence [6] occurs. Technologies 
that function at sub-IP layers can be enabled to provide further 
protection of IP traffic by providing the failure recovery at the 
sub-IP layers so that the outage is not observed at the IP layer. 
Such sub-IP protection technologies include, but are not limited to, 
High Availability (HA) stateful failover, Virtual Router Redundancy 
Protocol (VRRP) [8], Automatic Link Protection (APS) for SONET/SDH, 
Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for 
Multiprotocol Label Switching (MPLS-FRR) [9]. 


.1. Scope 


Benchmarking terminology was defined for IP-layer convergence in [6]. 
Different terminology and methodologies specific to benchmarking sub- 
IP layer protection mechanisms are required. The metrics for 
benchmarking the performance of sub-IP protection mechanisms are 
measured at the IP layer, so that the results are always measured in 
reference to IP and independent of the specific protection mechanism 
being used. The purpose of this document is to provide a single 
terminology for benchmarking sub-IP protection mechanisms. 


A common terminology for sub-IP layer protection mechanism 
benchmarking enables different implementations of a protection 
mechanism to be benchmarked and evaluated. In addition, 
implementations of different protection mechanisms can be benchmarked 
and evaluated. It is intended that there can exist unique 
methodology documents for each sub-IP protection mechanism based upon 
this common terminology document. The terminology can be applied to 
methodologies that benchmark sub-IP protection mechanism performance 
with a single stream of traffic or multiple streams of traffic. The 
traffic flow may be unidirectional or bidirectional as to be 
indicated in the methodology. 
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1.2. General Model 


The sequence of events to benchmark the performance of sub-IP 
protection mechanisms is as follows: 


1. Failover Event - Primary Path fails 
2. Failure Detection - Failover Event is detected 
3. Failover - Backup Path becomes the Working Path due to Failover 


Event 
4. Restoration - Primary Path recovers from a Failover Event 
5. Reversion (optional) - Primary Path becomes the Working Path 


These terms are further defined in this document. 


Figures 1 through 5 show models that MAY be used when benchmarking 
sub-IP protection mechanisms, which MUST use a Protection-Switching 
System that consists of a minimum of two Protection-Switching Nodes, 
an Ingress Node known as the Headend Node and an Egress Node known as 
the Merge Node. The Protection-Switching System MUST include either 
a Primary Path and Backup Path, as shown in Figures 1 through 4, or a 
Primary Node and Standby Node, as shown in Figure 5. A Protection- 
Switching System may provide link protection, node protection, path 
protection, local link protection, and high availability, as shown in 
Figures 1 through 5, respectively. A Failover Event occurs along the 
Primary Path or at the Primary Node. The Working Path is the Primary 
Path prior to the Failover Event and the Backup Path after the 
Failover Event. A Tester is set outside the two paths or nodes as it 
sends and receives IP traffic along the Working Path. The tester 
MUST record the IP packet sequence numbers, departure time, and 
arrival time so that the metrics of Failover Time, Additive Latency, 
Packet Reordering, Duplicate Packets, and Reversion Time can be 
measured. The Tester may be a single device or a test system. If 
Reversion is supported, then the Working Path is the Primary Path 
after Restoration (Failure Recovery) of the Primary Path. 


Link Protection, as shown in Figure 1, provides protection when a 
Failover Event occurs on the link between two nodes along the Primary 
Path. Node Protection, as shown in Figure 2, provides protection 
when a Failover Event occurs at a Node along the Primary Path. Path 
Protection, as shown in Figure 3, provides protection for link or 
node failures for multiple hops along the Primary Path. Local Link 
Protection, as shown in Figure 4, provides sub-IP protection of a 
link between two nodes, without a Backup Node. An example of such a 
sub-IP protection mechanism is SONET APS. High Availability 
Protection, as shown in Figure 5, provides protection of a Primary 
Node with a redundant Standby Node. State Control is provided 
between the Primary and Standby Nodes. Failure of the Primary Node 
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is detected at the sub-IP layer to force traffic to switch to the 
Standby Node, which has state maintained for zero or minimal packet 


loss. 
$ + 
LO O | Tester RSS Sse IAA + 
| #----------- + | 
| IP Traffic | Failover IP Traffic | 
| Event 
+--->| Ingress/ | v | Egress/ |---+ 
|Headend Node |------------------ |Merge Node| Primary 
A a ll ii. Path 
| A 
fo ooo | Backup 
Ho Backup . |------------- + Path 
Node 


Figure 1. System Under Test (SUT) for Sub-IP Link Protection 


+----------- + 
HOS Ste SS SSS sess sScSe | Tester |< E + 
| #----------- + | 
| IP Traffic | Failover IP Traffic | 
| | Event | 
| y | 
+--->| Ingress/ | |Midpoint | | Egress/ |---+ 
|Headend Node|----| Node |----|Merge Node| Primary 
SSSSsSsS3S2>  “S=SSS=s5° "PRES SES Path 
| A 
fo ooo | Backup 
Peas SaaS Backup — |------------- + Path 
Node 


Figure 2. System Under Test (SUT) for Sub-IP Node Protection 
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4+----------- + 
Pee Wa SS SSeS SSS Se SSS SSS Tester QS SSS SSS SSS SRS + 
4+----------- + 
IP Traffic | Failover IP Traffic 
| Event 


Primary Path | 


--->| Ingress/ | |Midpoint | V |Midpoint | | Egress/ |--- 
|Headend Node|----| Node |---| Node |---|Merge Node | 
| A 
Lo o -o | Backup 
Ho | Backup |----| Backup |-------- + Path 
Node | | Node 


Figure 3. System Under Test (SUT) for Sub-IP Path Protection 


4+----------- + 
Pec H SSS AA ssSS | Tester | <------------------- + 
| #----------- + | 
IP Traffic Failover IP Traffic 
Event 
| Primary | | 
| t-------- + Path v +-------- + | 
ee UA > >| ) | 
+--->| Ingress| | Egress |----+ 
Node |- ----------- >| Node | 
Ho + Backup Path prsmi + 


| IP-Layer Forwarding | 


Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection 
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Ho + 
oS S SSS SSS SSS Tester a aa 29 + 
t----------- + 
IP Traffic | Failover IP Traffic 
| | Event | 
| E | 
+--->| Ingress | [Primary | | Egress/ |------ + 
| Node |----| Node |----|Merge Node| Primary 
=== SE | CEA AE ARES Path 
State |Control a 


| 
| Interface | (Optional) | 
| 


| Node | 


Figure 5. System Under Test (SUT) 
for Sub-IP Redundant Node Protection 


Some protection-switching technologies may use a series of steps that 
differ from the general model. The specific differences SHOULD be 
highlighted in each technology-specific methodology. Note that some 
protection-switching technologies are endowed with the ability to re- 
optimize the working path after a node or link failure. 


2. Existing Definitions 


This document uses existing terminology defined in other BMWG work. 
Examples include, but are not limited to: 


Latency [2], Section 3.8 
Frame Loss Rate [2], Section 3.6 
Throughput [2], Section 3.17 
Device Under Test (DUT) [31], Section 3.1.1 
System Under Test (SUT) [3], Section 3.1.2 
Offered Load [3], Section 3.5.2 
Out-of-order Packet [4], Section 3.3.4 
Duplicate Packet [4], Section 3.3.5 
Forwarding Delay [4], Section 3.2.4 
Jitter [4], Section 3.2.5 
Packet Loss [6], Section 3.5 
Packet Reordering [7], Section 3.3 


This document has the following frequently used acronyms: 


DUT Device Under Test 
SUT System Under Test 
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This document adopts the definition format in Section 2 of RFC 1242 
[2]. Terms defined in this document are capitalized when used within 
this document. 


The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 [5]. 
RFC 2119 defines the use of these keywords to help make the intent of 
Standards Track documents as clear as possible. While this document 
uses these keywords, this document is not a Standards Track document. 


3. Test Considerations 
3.1. Paths 


3.1.1. Path 


Definition: 
A unidirectional sequence of nodes <R1, ..., Rn> and links 
<L12,... L(n-1)n> with the following properties: 


a. Rl is the ingress node and forwards IP packets, which input 
into DUT/SUT, to R2 as sub-IP frames over link L12. 


b. Ri is a node which forwards data frames to R(i+1) over Link 
Li(i+1) for all i, 1<i<n-1, based on information in the sub-IP 
layer. 


c. Rn is the egress node, and it outputs sub-IP frames from 
DUT/SUT as IP packets. L(n-1)n is the link between the R(n-1) 


and Rn. 
Discussion: 
The path is defined in the sub-IP layer in this document, unlike 
an IP path in RFC 2026 [1]. One path may be regarded as being 


equivalent to one IP link between two IP nodes, i.e., RI and Rn. 
The two IP nodes may have multiple paths for protection. A packet 
will travel on only one path between the nodes. Packets belonging 
to a microflow [10] will traverse one or more paths. The path is 
unidirectional. For example, the link between R1 and R2 in the 
direction from R1 to R2 is L12. For traffic flowing in the 
reverse direction from R2 to R1, the link is L21. Example paths 
are the SONET/SDH path and the label switched path for MPLS. 


Measurement Units: 
n/a 
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Issues: 
"A bidirectional path", which transmits traffic in both directions 
along the same nodes, consists of two unidirectional paths. 
Therefore, the two unidirectional paths belonging to "one 
bidirectional path" will be treated independently when 
benchmarking for "a bidirectional path". 


See Also: 
Working Path 
Primary Path 
Backup Path 


3.1.2. Working Path 


Definition: 
The path that the DUT/SUT is currently using to forward packets. 


Discussion: 
A Primary Path is the Working Path before occurrence of a Failover 
Event. A Backup Path shall become the Working Path after a 
Failover Event. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Path 
Primary Path 
Backup Path 


3.1.3. Primary Path 
Definition: 
The preferred point-to-point path for forwarding traffic between 
two or more nodes. 
Discussion: 
The Primary Path is the Path that traffic traverses prior toa 


Failover Event. 


Measurement Units: 
n/a 


Issues: 
None. 
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See Also: 
Path 
Failover Event 


3.1.4. Protected Primary Path 


Definition: 
A Primary Path that is protected with a Backup Path. 


Discussion: 
A Protected Primary Path must include at least one Protection- 
Switching Node. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Path 
Primary Path 


3.1.5. Backup Path 


Definition: 
A path that exists to carry data traffic only if a Failover Event 
occurs on a Primary Path. 


Discussion: 
The Backup Path shall become the Working Path upon a Failover 
Event. A Path may have one or more Backup Paths. A Backup Path 
may protect one or more Primary Paths. There are various types of 
Backup Paths: 


a. dedicated recovery Backup Path (1+1) or (1:1), which has 100% 
redundancy for a specific ordinary path 


b. shared Backup Path (1:N), which is dedicated to the protection 
for more than one specific Primary Path 


c. associated shared Backup Path (M:N) for which a specific set of 


Backup Paths protects a specific set of more than one Primary 
Path 
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A Backup Path may be signaled or unsignaled. The Backup Path must 
be created prior to the Failover Event. The Backup Path generally 
originates at the point of local repair (PLR) and terminates at a 
node along a primary path. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Path 
Working Path 
Primary Path 


3.1.6. Standby Backup Path 


Definition: 
A Backup Path that is established prior to a Failover Event to 
protect a Primary Path. 


Discussion: 
The Standby Backup Path and Dynamic Backup Path provide 
protection, but are established at different times. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Backup Path 
Primary Path 
Failover Event 


3.1.7. Dynamic Backup Path 
Definition: 
A Backup Path that is established upon occurrence of a Failover 
Event. 
Discussion: 


The Standby Backup Path and Dynamic Backup Path provide 
protection, but are established at different times. 
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Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Backup Path 
Standby Backup Path 
Failover Event 


3.1.8. Disjoint Paths 


Definition: 
A pair of paths that do not share a common link or nodes. 


Discussion: 


Two paths are disjoint if they do not share a common node or link 
other than the ingress and egress. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Path 
Primary Path 
SRLG 


3.1.9. Point of Local Repair (PLR) 


Definition: 
A node capable of Failover along the Primary Path that is also the 
ingress node for the Backup Path to protect another node or link. 


Discussion: 
Any node along the Primary Path from the ingress node to the 
penultimate node may be a PLR. The PLR may use a single Backup 
Path for protecting one or more Primary Paths. There can be 
multiple PLRs along a Primary Path. The PLR must be an ingress to 
a Backup Path. The PLR can be any node along the Primary Path 
except the egress node of the Primary Path. The PLR may 
simultaneously be a Headend Node when it is serving the role as 
ingress to the Primary Path and the Backup Path. If the PLR is 
also the Headend Node, then the Backup Path is a Disjoint Path 
from the ingress to the Merge Node. 
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Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 
Backup Path 
Failover 


3.1.10. Shared Risk Link Group (SRLG) 
Definition: 


SRLG is a set of links that share the same risk (physical or 
logical) within a network. 


Discussion: 
SRLG is considered the set of links to be avoided when the primary 
and secondary paths are considered disjoint. The SRLG will fail 


as a group if the shared resource (physical or anything abstract 
such as software version) fails. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Path Primary Path 


3.2. Protection 
3.2.1. Link Protection 
Definition: 
A Backup Path that is signaled to at least one Backup Node to 
protect for failure of interfaces and links along a Primary Path. 
Discussion: 
Link Protection may or may not protect the entire Primary Path. 


Link Protection is shown in Figure 1. 


Measurement Units: 
n/a 
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Issues: 
None. 


See Also: 
Primary Path Backup Path 


3.2.2. Node Protection 


Definition: 
A Backup Path that is signaled to at least one Backup Node to 
protect for failure of interfaces, links, and nodes along a 
Primary Path. 


Discussion: 
Node Protection may or may not protect the entire Primary Path. 
Node Protection also provides Link Protection. Node Protection is 
shown in Figure 2. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Link Protection 


3.2.3. Path Protection 


Definition: 
A Backup Path that is signaled to at least one Backup Node to 
provide protection along the entire Primary Path. 


Discussion: 
Path Protection provides Node Protection and Link Protection for 
every node and link along the Primary Path. A Backup Path 
providing Path Protection may have the same ingress node as the 
Primary Path. Path Protection is shown in Figure 3. 


Measurement Units: 
n/a 


Issues: 
None. 
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See Also: 
Primary Path 
Backup Path 
Node Protection 
Link Protection 


3.2.4. Backup Span 


Definition: 
The number of hops used by a Backup Path. 


Discussion: 
The Backup Span is an integer obtained by counting the number of 
nodes along the Backup Path. 


Measurement Units: 
number of nodes 


Issues: 
None. 


See Also: 
Primary Path 
Backup Path 


3.2.5. Local Link Protection 


Definition: 
A Backup Path that is a redundant path between two nodes and does 
not use a Backup Node. 


Discussion: 
Local Link Protection must be provided as a Backup Path between 
two nodes along the Primary Path without the use of a Backup Node. 
Local Link Protection is provided by Protection-Switching Systems 
such as SONET APS. Local Link Protection is shown in Figure 4. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 


Backup Path 
Backup Node 
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3.2.6. Redundant Node Protection 


Definition: 
A Protection-Switching System with a Primary Node protected by a 
Standby Node along the Primary Path. 


Discussion: 
Redundant Node Protection is provided by Protection-Switching 
Systems such as VRRP and HA. The protection mechanisms occur at 
sub-IP layers to switch traffic from a Primary Node to Backup Node 
upon a Failover Event at the Primary Node. Traffic continues to 
traverse the Primary Path through the Standby Node. The failover 
may be stateful, in which the state information may be exchanged 
in-band or over an out-of-band State Control Interface. The 
Standby Node may be active or passive. Redundant Node Protection 
is shown in Figure 5. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 
Primary Node 
Standby Node 


3.2.7. State Control Interface 


Definition: 
An out-of-band control interface used to exchange state 
information between the Primary Node and Standby Node. 


Discussion: 
The State Control Interface may be used for Redundant Node 
Protection. The State Control Interface should be out-of-band. 
It is possible to have Redundant Node Protection in which there is 
no state control or state control is provided in-band. The State 
Control Interface between the Primary and Standby Node may be one 
or more hops. 


Measurement Units: 
n/a 


Issues: 
None. 
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See Also: 
Primary Node 
Standby Node 


3.2.8. Protected Interface 


Definition: 
An interface along the Primary Path that is protected by a Backup 
Path. 


Discussion: 
A Protected Interface is an interface protected by a Protection- 
Switching System that provides Link Protection, Node Protection, 
Path Protection, Local Link Protection, and Redundant Node 
Protection. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 
Backup Path 


3.3. Protection Switching 
3.3.1. Protection-Switching System 


Definition: 
A DUT/SUT that is capable of Failure Detection and Failover from a 
Primary Path to a Backup Path or Standby Node when a Failover 
Event occurs. 


Discussion: 
The Protection-Switching System must include either a Primary Path 
and Backup Path, as shown in Figures 1 through 4, or a Primary 
Node and Standby Node, as shown in Figure 5. The Backup Path may 
be a Standby Backup Path or a Dynamic Backup Path. The 
Protection-Switching System includes the mechanisms for both 
Failure Detection and Failover. 


Measurement Units: 
n/a 


Issues: 
None. 
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See Also: 
Primary Path Backup Path Failover 


3.3.2. Failover Event 


Definition: 
The occurrence of a planned or unplanned action in the network 
that results in a change in the Path that data traffic traverses. 


Discussion: 
Failover Events include, but are not limited to, link failure and 
router failure. Routing changes are considered Convergence Events 
[6] and are not Failover Events. This restricts Failover Events 
to sub-IP layers. Failover may be at the PLR or at the ingress. 
If the failover is at the ingress, it is generally on a disjoint 
path from the ingress to egress. 


Failover Events may result from failures such as link failure or 
router failure. The change in path after Failover may have a 
Backup Span of one or more nodes. Failover Events are 
distinguished from routing changes and Convergence Events [6] by 
the detection of the failure and subsequent protection switching 
at a sub-IP layer. Failover occurs at a PLR or Primary Node. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Path 
Failure Detection 
Disjoint Path 


3.3.3. Failure Detection 


Definition: 
The process to identify at a sub-IP layer a Failover Event at a 
Primary Node or along the Primary Path. 


Discussion: 
Failure Detection occurs at the Primary Node or ingress node of 
the Primary Path. Failure Detection occurs via a sub-IP mechanism 
such as detection of a link down event or timeout for receipt of a 
control packet. A failure may be completely isolated. A failure 
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may affect a set of links that share a single SRLG (e.g., port 
with many sub-interfaces). A failure may affect multiple links 
that are not part of the SRLG. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 


3.3.4. Failover 


Definition: 
The process to switch data traffic from the protected Primary Path 
to the Backup Path upon Failure Detection of a Failover Event. 


Discussion: 
Failover to a Backup Path provides Link Protection, Node 
Protection, or Path Protection. Failover is complete when Packet 
Loss [6], Out-of-order Packets [4], and Duplicate Packets [4] are 
no longer observed. Forwarding Delay [4] may continue to be 
observed. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path Backup Path Failover Event 


3.3.5. Restoration 


Definition: 
The state of failover recovery in which the Primary Path has 
recovered from a Failover Event, but is not yet forwarding packets 
because the Backup Path remains the Working Path. 


Discussion: 
Restoration must occur while the Backup Path is the Working Path. 
The Backup Path is maintained as the Working Path during 
Restoration. Restoration produces a Primary Path that is 
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recovered from failure, but is not yet forwarding traffic. 
Traffic is still being forwarded by the Backup Path functioning as 
the Working Path. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 
Failover Event 
Failure Recovery 
Working Path 
Backup Path 


3.3.6. Reversion 


Definition: 
The state of failover recovery in which the Primary Path has 
become the Working Path so that it is forwarding packets. 


Discussion: 
Protection-Switching Systems may or may not support Reversion. 
Reversion, if supported, must occur after Restoration. Packet 
forwarding on the Primary Path resulting from Reversion may occur 
either fully or partially over the Primary Path. A potential 
problem with Reversion is the discontinuity in end-to-end delay 
when the Forwarding Delays [4] along the Primary Path and Backup 
Path are different, possibly causing Out-of-order Packets [4], 
Duplicate Packets [4], and increased Jitter [4]. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Protection-Switching System 
Working Path 
Primary Path 
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3.4. Nodes 
3.4.1. Protection-Switching Node 


Definition: 
A node that is capable of participating in a Protection Switching 
System. 


Discussion: 
The Protection-Switching Node may be an ingress or egress for a 
Primary Path or Backup Path, such as used for MPLS Fast Reroute 
configurations. The Protection-Switching Node may provide 
Redundant Node Protection as a Primary Node in a Redundant chassis 
configuration with a Standby Node, such as used for VRRP and HA 
configurations. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Protection-Switching System 


3.4.2. Non-Protection-Switching Node 


Definition: 
A node that is not capable of participating in a Protection 
Switching System, but may exist along the Primary Path or Backup 
Path. 


Discussion: 
None. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Protection-Switching System 
Primary Path 
Backup Path 
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3.4.3. Headend Node 


Definition: 
The ingress node of the Primary Path. 


Discussion: 
The Headend Node may also be a PLR when it is serving in the dual 
role as the ingress to the Backup Path. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 
PLR 
Failover 


3.4.4. Backup Node 


Definition: 
A node along the Backup Path. 


Discussion: 
The Backup Node can be any node along the Backup Path. There may 
be one or more Backup Nodes along the Backup Path. A Backup Node 
may be the ingress, midpoint, or egress of the Backup Path. If 
the Backup Path has only one Backup Node, then that Backup Node is 
the ingress and egress of the Backup Path. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Backup Path 
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Bis 


3: 


4. 


4. 


5. Merge Node 


Definition: 
A node along the Primary Path where Backup Path terminates. 


Discussion: 
The Merge Node can be any node along the Primary Path except the 
ingress node of the Primary Path. There can be multiple Merge 
Nodes along a Primary Path. A Merge Node can be the egress node 
for a single Backup Path or multiple Backup Paths. The Merge Node 
must be the egress to the Backup Path. The Merge Node may also be 
the egress of the Primary Path or Point of Local Repair (PLR). 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Primary Path 
Backup Path 
PLR 
Failover 


6. Primary Node 


Definition: 
A node along the Primary Path that is capable of Failover toa 
redundant Standby Node. 


Discussion: 
The Primary Node may be used for Protection-Switching Systems that 
provide Redundant Node Protection, such as VRRP and HA. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 
Protection-Switching System Redundant Node Protection Standby Node 
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3.4.7. Standby Node 


Definition: 
A redundant node to a Primary Node; it forwards traffic along the 
Primary Path upon Failure Detection of the Primary Node. 


Discussion: 
The Standby Node must be used for Protection-Switching Systems 
that provide Redundant Node Protection, such as VRRP and HA. The 
Standby Node must provide protection along the same Primary Path. 
If the failover is to a Disjoint Path, then it is a Backup Node. 
The Standby Node may be configured for 1:1 or N:1 protection. 


The communication between the Primary Node and Standby Node may be 
in-band or across an out-of-band State Control Interface. The 
Standby Node may be geographically dispersed from the Primary 
Node. When geographically dispersed, the number of hops of 
separation may increase failover time. 


The Standby Node may be passive or active. The Passive Standby 
Node is not offered traffic and does not forward traffic until 
Failure Detection of the Primary Node. Upon Failure Detection of 
the Primary Node, traffic offered to the Primary Node is instead 
offered to the Passive Standby Node. The Active Standby Node is 
offered traffic and forwards traffic along the Primary Path while 
the Primary Node is also active. Upon Failure Detection of the 
Primary Node, traffic offered to the Primary Node is switched to 
the Active Standby Node. 


Measurement Units: 
n/a 


Issues: 
None. 


See Also: 


Primary Node 
State Control Interface 
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3.5. Benchmarks 
3.5.1. Failover Packet Loss 


Definition: 
The amount of packet loss produced by a Failover Event until 
Failover completes, where the measurement begins when the last 
unimpaired packet is received by the Tester on the Protected 
Primary Path and ends when the first unimpaired packet is received 
by the Tester on the Backup Path. 


Discussion: 
Packet loss can be observed as a reduction of forwarded traffic 
from the maximum forwarding rate. Failover Packet Loss includes 
packets that were lost, reordered, or delayed. Failover Packet 
Loss may reach 100% of the offered load. 


Measurement Units: 
Number of Packets 


Issues: 
None. 


See Also: 
Failover Event 
Failover 


3.5.2. Reversion Packet Loss 


Definition: 
The amount of packet loss produced by Reversion, where the 
measurement begins when the last unimpaired packet is received by 
the Tester on the Backup Path and ends when the first unimpaired 
packet is received by the Tester on the Protected Primary Path. 


Discussion: 
Packet loss can be observed as a reduction of forwarded traffic 
from the maximum forwarding rate. Reversion Packet Loss includes 
packets that were lost, reordered, or delayed. Reversion Packet 
Loss may reach 100% of the offered load. 


Measurement Units: 
Number of Packets 


Issues: 
None. 
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See Also: 
Reversion 


3.5.3. Failover Time 


Definition: 
The amount of time it takes for Failover to successfully complete. 


Discussion: 
Failover Time can be calculated using the Time-Based Loss Method 
(IBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method 
(TBM). It is RECOMMENDED that the TBM is used. 


Measurement Units: 
milliseconds 


Issues: 
None. 


See Also: 
Failover 
Failover Time 
Time-Based Loss Method (TBLM) 
Packet-Loss-Based Method (PLBM) 
Timestamp-Based Method (TBM) 


3.5.4. Reversion Time 


Definition: 
The amount of time it takes for Reversion to complete so that the 
Primary Path is restored as the Working Path. 


Discussion: 
Reversion Time can be calculated using the Time-Based Loss Method 
(IBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method 
(TBM). It is RECOMMENDED that the TBM is used. 


Measurement Units: 
milliseconds 


Issues: 
None. 


See Also: 
Reversion 
Primary Path 
Working Path 
Reversion Packet Loss 
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Time-Based Loss Method (TBLM) 
Packet-Loss-Based Method (PLBM) 
Timestamp-Based Method (TBM) 


3.5.5. Additive Backup Delay 


Definition: 
The amount of increased Forwarding Delay [4] resulting from data 
traffic traversing the Backup Path instead of the Primary Path. 


Discussion: 
Additive Backup Delay is calculated using Equation 1 as shown 
below: 


(Equation 1) 

Additive Backup Delay = 

Forwarding Delay (Backup Path) - 
Forwarding Delay(Primary Path) 


Measurement Units: 
milliseconds 


Issues: 
Additive Backup Latency may be a negative result. This is 
theoretically possible but could be indicative of a sub-optimum 
network configuration. 


See Also: 
Primary Path 
Backup Path 
Primary Path Latency 
Backup Path Latency 


3.6. Failover Time Calculation Methods 


The following Methods may be assessed on a per-flow basis using at 
least 16 flows spread over the routing table (using more flows is 
better). Otherwise, the impact of a prefix-dependency in the 
implementation of a particular protection technology could be missed. 
However, the test designer must be aware of the number of packets per 
second sent to each prefix, as this establishes sampling of the path 
and the time resolution for measurement of Failover time on a per- 
flow basis. 
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3.6.1. Time-Based Loss Method (TBLM) 


Definition: 
The method to calculate Failover Time (or Reversion Time) using a 
time scale on the Tester to measure the interval of Failover 
Packet Loss. 


Discussion: 
The Tester must provide statistics that show the duration of 
failure on a time scale based on occurrence of packet loss ona 
time scale. This is indicated by the duration of non-zero packet 
loss. The TBLM includes failure detection time and time for data 
traffic to begin traversing the Backup Path. Failover Time and 
Reversion Time are calculated using the TBLM as shown in Equation 
2: 


(Equation 2) 
(Equation 2a) 
TBLM Failover Time = Time (Failover) - Time (Failover Event) 


(Equation 2b) 
TBLM Reversion Time = Time (Reversion) - Time (Restoration) 


Where 
Time (Failover) = Time on the tester at the receipt of the first 


unimpaired packet at egress node after the backup path became the 
working path 


Time (Failover Event) = Time on the tester at the receipt of the 
last unimpaired packet at egress node on the primary path before 
failure 


Measurement Units: 
milliseconds 


Issues: 
None. 


See Also: 
Failover 
Packet-Loss-Based Method 
3.6.2. Packet-Loss-Based Method (PLBM) 
Definition: 


The method used to calculate Failover Time (or Reversion Time) 
from the amount of Failover Packet Loss. 
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Discussion: 
PLBM includes failure detection time and time for data traffic to 
begin traversing the Backup Path. Failover Time can be calculated 
using PLBM from the amount of Failover Packet Loss as shown below 
in Equation 3. Note: If traffic is sent to more than 1 
destination, PLBM gives the average loss over the measured 
destinations. 


(Equation 3) 
(Equation 3a) 
PLBM Failover Time = 
(Number of packets lost / Offered Load rate) * 1000) 


(Equation 3b) 
PLBM Restoration Time = 
(Number of packets lost / Offered Load rate) * 1000) 


Units are packets/ (packets/second) = seconds 


Measurement Units: 
milliseconds 


Issues: 
None. 


See Also: 
Failover Time-Based Loss Method 


3.6.3. Timestamp-Based Method (TBM) 


Definition: 
The method to calculate Failover Time (or Reversion Time) using a 
time scale to quantify the interval between unimpaired packets 
arriving in the test stream. 


Discussion: 
The purpose of this method is to quantify the duration of failure 
or reversion on a time scale based on the observation of 
unimpaired packets. The TBM is calculated from Equation 2 with 
the values obtained from the timestamp in the packet payload, 
rather than from the Tester clock (which are used with the TBLM). 


Unimpaired packets are normal packets that are not lost, 
reordered, or duplicated. A reordered packet is defined in 
Section 3.3 of [7]. A duplicate packet is defined in Section 
3.3.5 of [4]. Unimpaired packets may be detected by checking a 
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sequence number in the payload, where the sequence number equals 
the next expected number for an unimpaired packet. A sequence gap 
or sequence reversal indicates impaired packets. 


For calculating Failover Time, the TBM includes failure detection 
time and time for data traffic to begin traversing the Backup 
Path. For calculating Reversion Time, the TBM includes Reversion 
Time and time for data traffic to begin traversing the Primary 
Path. 


Measurement Units: 
milliseconds 


Issues: 
None. 


See Also: 
Failover 
Failover Time 
Reversion 
Reversion Time 


4. Security Considerations 


Benchmarking activities as described in this memo are limited to 
technology characterization using controlled stimuli in a laboratory 
environment, with dedicated address space and the constraints 
specified in the sections above. 


The benchmarking network topology will be an independent test setup 
and MUST NOT be connected to devices that may forward the test 
traffic into a production network or misroute traffic to the test 
management network. 


Further, benchmarking is performed on a "black-box" basis, relying 
solely on measurements observable external to the DUT/SUT. 


Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 
benchmarking purposes. Any implications for network security arising 
from the DUT/SUT SHOULD be identical in the lab and in production 
networks. 
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